Ventajas de usar estándares web
Entre los muchísimos argumentos a favor de tener el contenido editorial en ficheros de lenguaje estándar HTML y CSS, el reciente artículo de R. Scot Johns, Why I don't use ebook creation apps (but you might want to anyway), nos ha parecído particularmente simpático a la vez que realista, razón por la que lo hemos traducido al español.
Hace muchos años hice mi primer sitio web, usando Dreamweaver. Creo que era la versión 8.1, de cuando todavía era Macromedia. El sitio web era muy básico, el programa muy complejo. El programa se ajustaba a mis necesidades de entonces y tenía un gran potencial para extender las funcionalidades… si yo hubiera querido aprender a codificar una web compleja, claro. Pero no quería.
Así que cuando me llegó el momento de querer añadir a mi web una tienda donde se pudieran comprar libros electrónicos e impresos, me cambié a Yahoo SiteBuilder, ya que en aquel momento era el mejor servicio de hospedaje y ofrecía un simple add-on para crear un carrito de compra (por una cuota, por supuesto). Pero como Yahoo usaba código propio para el diseño y funcionalidad de las páginas, tuve que reconstruir desde el principio todo mi sitio web, ya que era imposible importar mi sitio y construir lo nuevo sobre dicha importación. Sin embargo, después de aburridos esfuerzos (por no mencionar el tener que aprender toda la nueva interface del software) conseguí un bonito sitio web que satisfizo mis necesidades … durante un tiempo.
Pero la tecnología de la web siguió adelante y Yahoo no. Con el tiempo quise actualizar mi sitio web con las fantásticas nuevas funcionalidades disponibles en HTML5 y CSS3. Pero eso no se podía hacer en Yahoo.
Así que trasladé mi sitio web a la plataforma web de otro poveedor…y rehice el sitio de nuevo desde el principio, ya que el super secreto código de Yahoo no puede ser transferido a otra plataforma.
Aquel proveedor quebró un año después ( Yahoo apenas ha conseguido mantenerse a flote).
Así que una vez más tuve que recomenzar y construir mi sitio web desde el principio (la cuarta vez, para quienes quieran llevar la cuenta). Esta vez decidí usar la popular plataforma “abierta” Wordpress, con su estructura de plantillas tan personalizables, pensando que sería más “universal”, ya que tenía disponibles un casi infinito número de plantillas y paquetes de extensión.
Pero WordPress ha demostrado ser lento y perezoso, se queda colgado con frecuencia y pierde datos casi siempre que se actualiza a una nueva versión. Y como todas sus funcionalidades, excepto las básicas, se manejan añadiendo extensiones de terceros (cuya compatibilidad sólo ha sido probada respecto a la plataforma básica), frecuentemente entran en conflicto unas extensiones con otras, lo que provoca que funcionalidades o secciones enteras del sitio funcionen mal (o no funcionen en absoluto), provocan el colapso del sitio cuando cualquiera de estas extensiones se actualiza, incluso encerrándolo en un bucle perpetuo en más de una ocasión, bucle que sólo se puede romper borrando una o más extensiones, con lo que se pierden todos los datos afectados por dichas extensiones.
Además, debido a la propia naturaleza de esta metodología de “plug-in”, el sitio resultaba de nuevo no exportable a cualquier otra plataforma. Así que una vez más me enfrenté a la aparentemente inevitable tarea de reconstruir mi sitio desde la base.
Es así como después de construir mi sitio web cinco veces, estoy de vuelta donde empecé, usando Dreamweaver para hacer todo su contenido con código universalmente reconocible basado en HTML y CSS estándar. Es infinitamente ampliable, limitado sólo por mi tiempo y disposición a aprender, y puede transferirse de un servicio de hospedaje a otro cuando quiera. Es el mejor sitio que he construido hasta ahora. Y aún más importante, el código subyacente se puede leer y editar con cualquier editor de texto estándar. Puedo arreglar mi sitio si se viene abajo, y añadir nuevas funcionalidades en la medida que aprendo a implementar nuevo código. Si veo algo que me gusta en otro sitio web, puedo ver su código fuente en mi navegador y ver como se ha hecho. No estoy limitado por lo que el software puede hacer, sino por lo que yo puedo hacer.
En este punto te puedes preguntar qué tiene ésto que ver con los ebooks.
Un ebook es, en esencia, símplemente un sitio web portatil, con un diseño de página fijo o adaptable, y basado en un subconjunto del mismo HTML y CSS que usa un sitio web. Tú sólo tienes que aprender las pizcas de código que hacen que el ebook funcione, y el resto queda a tu imaginación.
Los mismos problemas que me acosaron durante tantos años en la construcción de mi sitio web también se aplican en la construcción de ebooks, así que sigue mi consejo. Los programas que construyen el libro por ti lo hacen usando un código particular que normalmente no lo entienden los meros mortales como nosotros (a no ser que tengas la paciencia de un santo, o la sabiduría de un dios, que no es mi caso). Por ejemplo, cambian los nombres de los ficheros con tus contenidos, de forma que en lugar de tener pagina23revestimiento2.jpg, te puedes encontrar en su lugar img000172.jpg en tu nueva página HTML, a la que ahora llaman split0000159.xhtml. Te deseo suerte en encontrar el fichero correcto para la página 23. O las imágenes que contiene, si decides cambiar alguna.
Las cosas se ponen aún peor por el hecho de que todas tus entradas de CSS que habías cuidadosamente etiquetado se cambiarán de la misma forma, y tu instrucción de estilo #panelpagina23 ahora se llama data-app-amzn-ke-created-style0126, o algún sinsentido parecido. Y muy probablemente, todo tu primorosamente organizado HTML se une en una interminable ristra de código. Obviamente, esto no ayuda nada.
A no ser que seas una máquina. Y una máquina muy particular.
Esto es de aplicación no sólo a la herramienta de creación de comics y libros infantiles de Amazon, sino también en diferentes grados a iBooks Author, a la función de InDesign para exportar como ebooks, y a los editores de ebooks como Calibre y Sigil. El código que crean sólo puede leerse de forma efectiva por ellos mismos, obligándote así a usar la misma plataforma en todas las futuras actualizaciones de ese fichero, hasta que llega la hora en que dicha plataforma ya no es útil, o pasa a ser incompatible con tu anticuado fichero (o sistema operativo) después de una actualización, o la compañía quiebra.
Entonces te enfrentas al mismo dilema al que yo me enfrenté haciendo sitios web.
Tendrás que rehacer tus libros completamente.
Empezando de cero.
De nuevo.